-
Notifications
You must be signed in to change notification settings - Fork 13.3k
[CLANG] Enable alignas after GNU attributes #133107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
@llvm/pr-subscribers-clang Author: Denis.G (DenisGZM) ChangesEnable parsing alignas attribute after GNU attributes, before ParseDeclaration This might be useful for cuda code where shared and other specificators may be mixed with align. I'd be glad to see if there are any better places or other technique to process this attribute without interrupting current flow of parsing. Full diff: https://github.com/llvm/llvm-project/pull/133107.diff 2 Files Affected:
diff --git a/clang/lib/Parse/ParseStmt.cpp b/clang/lib/Parse/ParseStmt.cpp
index 150b2879fc94f..33b9f63bcfa08 100644
--- a/clang/lib/Parse/ParseStmt.cpp
+++ b/clang/lib/Parse/ParseStmt.cpp
@@ -296,6 +296,11 @@ StmtResult Parser::ParseStatementOrDeclarationAfterAttributes(
goto Retry;
}
+ case tok::kw_alignas: {
+ ParseAlignmentSpecifier(CXX11Attrs);
+ goto Retry;
+ }
+
case tok::kw_template: {
SourceLocation DeclEnd;
ParseTemplateDeclarationOrSpecialization(DeclaratorContext::Block, DeclEnd,
diff --git a/clang/test/SemaCUDA/cuda-attr-order.cu b/clang/test/SemaCUDA/cuda-attr-order.cu
new file mode 100644
index 0000000000000..d3bf5b014d1c6
--- /dev/null
+++ b/clang/test/SemaCUDA/cuda-attr-order.cu
@@ -0,0 +1,15 @@
+// Verify that we can parse a simple CUDA file with different attributes order.
+// RUN: %clang_cc1 "-triple" "nvptx-nvidia-cuda" -fsyntax-only -verify %s
+// expected-no-diagnostics
+#include "Inputs/cuda.h"
+
+struct alignas(16) float4 {
+ float x, y, z, w;
+};
+
+__attribute__((device)) float func() {
+ __shared__ alignas(alignof(float4)) float As[4][4]; // Both combinations
+ alignas(alignof(float4)) __shared__ float Bs[4][4]; // must be legal
+
+ return As[0][0] + Bs[0][0];
+}
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At a glance this does seem like the right place to do this, but this is still missing a release note.
It seems like GCC allows e.g. __attribute__(()) alignas(16) int x
in any case, so I don’t see why we shouldn’t allow this too. Can you also add some tests that use __attribute__(())
directly and which aren’t CUDA-specific?
Oh, and can you add solmething like this as a test as well:
struct S { __attribute__((deprecated)) alignas(16) int x; };
CC @erichkeane in case there’s a specific reason I’m not aware of as to why we currently don’t allow this. |
Actually this test doesn't work with this patch... In this case all attributes are processed in In ParseDecl.cpp
And AttrsLastTime is always false in declarations of the form: Another approach i tried is to add processing alignas-cxx11 just like it is done for C: kw__Alignas and kw_alignas (c23). |
Hmm, @erichkeane probably knows where this needs to be parsed then; I might take another look at this myself later (because I’m not sure either off the top of my head), but I’m rather busy today unfortunately... |
…MemberDeclaration
I added parsing all attributes in ParseCXXClassMemberDeclaration before calling ParseDeclarationSpecifiers and it seems to solve problem, but it also changes annotation ranges for struct and class members |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems reasonable to me, but I’d still like @erichkeane to take a look at this as the attributes code owner
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Parsing of attributes is admittedly the part I'm least comfortable with here. I would love tests for how this interacts with our __declspec
spelling attributes though, and to help determine why we wouldn't parse all 3 together here.
As a followup/future direction for some one, there is perhaps value of a MaybeParseAnyAttributes
that does all 3 in a loop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this looks reasonable? I would like @AaronBallman to stop by though, he might think of some reason why this isn't right per-grammar.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the fix! The changes should come with a release note in clang/docs/ReleaseNotes.rst
so users know about the fix.
Reworked approach for parsing. We needed to support arbitrary attribute parsing rather than just |
✅ With the latest revision this PR passed the C/C++ code formatter. |
@@ -24,7 +24,7 @@ int templateFunction(T value) __attribute__((annotate("works"))); | |||
|
|||
// CHECK: ClassDecl=Test:3:7 (Definition) Extent=[3:1 - 17:2] | |||
// CHECK-NEXT: CXXAccessSpecifier=:4:1 (Definition) Extent=[4:1 - 4:8] | |||
// CHECK-NEXT: CXXMethod=aMethod:5:51 Extent=[5:3 - 5:60] | |||
// CHECK-NEXT: CXXMethod=aMethod:5:51 Extent=[5:46 - 5:60] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This means we went from pointing to the start of __attribute__
to pointing to the start of void
which is a bit unfortunate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should avoid it somehow? Or just accept it as is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm on the fence. It's not the worst regression in behavior, but it does make the diagnostic slightly harder for users to reason about. WDYT @erichkeane ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
its really quite unfortunate... I think it is at least worth seeing how much work needs to be done to get this 'right', and see if it is worth the effort.
Enable parsing alignas attribute after GNU attributes, before ParseDeclaration
This might be useful for cuda code where shared and other specificators may be mixed with align.
I'd be glad to see if there are any better places or other technique to process this attribute without interrupting current flow of parsing.